perm filename IJCAI.PUB[HAL,HE] blob sn#153462 filedate 1975-04-10 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00008 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	.TURN ON "∞π↑↓[]{_α#←→&∂"
C00009 00003	.NEXT PAGE
C00012 00004	.NEWSEC AN OVERVIEW OF AL
C00017 00005	.NEWSS PHILOSOPHY OF DESIGN 
C00034 00006	.NEWSS GENERAL SYSTEM OUTLINE
C00043 00007	.NEWSEC AN EXAMPLE
C00058 00008	.NEWSEC CONCLUSIONS
C00066 ENDMK
C⊗;
.TURN ON "∞π↑↓[]{_α#←→&∂";
.TURN OFF TAB;
.SPACING  125 MILLS ;
.PREFACE 200 MILLS ;
.INDENT 4,0;
.NOFILL; PREFACE SPREAD; FILL;

.MACRO UNFILL ⊂BEGIN NOFILL;PREFACE 0;TURN OFF "←→";GROUP⊃;
.MACRO REFILL ⊂END; CONTINUE⊃;
.MACRO MAYBREAK ⊂APART;GROUP;⊃;
.MACRO BULL ⊂ONCE; FLUSH LEFT⊃;
.MACRO COMT(X) ⊂BEGIN FILL;PREFACE 125 MILLS;INDENT X,X;}%4{⊃

.COUNT SECTION FROM 1 TO 99 PRINTING ⊂SECTION⊃;
.COUNT SUBSEC FROM 0 TO 99 IN SECTION PRINTING "!.1";
.COUNT SUBSUBSEC FROM 0 TO 99 IN SUBSEC PRINTING "!.1";
.COUNT FOOTNOTE INLINE FROM 1 TO 9 IN PAGE;

.MACRO NEWSEC(TITLE,ID) ⊂
.NEXT SECTION!;
.IF PICLIN≠NULL THEN ALLPIC;
.SECNAME←NULL;
.SSECNAME←NULL;
.SSSNUM←NULL
.NEXT SUBSEC;TABLE←0;
.SECNAME←"TITLE";
.SSECNAME←"ID";
.BEGIN INDENT 0,0;
.SKIP 2;
%5{SECTION!}   {SECNAME}%*
.END
.SECNAME←"TITLE";⊃


.MACRO NEWSS(TITLE,ID,LAB) ⊂
.NEXT SUBSEC!;
.IF PICLIN≠NULL THEN ALLPIC;
.SSSNUM←SUBSEC!
.NEXT SUBSUBSEC;
.BEGIN INDENT 0,0;
.IF LINES≤8*SPREAD THEN NEXT PAGE ELSE SKIP 2*SPREAD;
.SSECNAME←"ID";
.IF SSECNAME=NULL THEN SSECNAME←"TITLE";
%5{SUBSEC!}      TITLE%*
.END
.⊃

.MACRO NEWSSS(TITLE,LAB) ⊂
.NEXT SUBSUBSEC!;
.IF PICLIN≠NULL THEN ALLPIC;
.SSSNUM←SUBSUBSEC!
.BEGIN INDENT 0,0;
.IF LINES≤6*SPREAD THEN NEXT PAGE ELSE SKIP 1+SPREAD;
%4TITLE%*
.END
.BREAK
.⊃

.MACRO SECREF(LBL)⊂"Section ";SECTION! LBL⊃
.MACRO SSREF(LBL)⊂"Section ";SUBSEC! LBL ⊃
.MACRO SSSREF(LBL)⊂"Section ";SUBSEC! LBL⊃
.AT NULL ⊂IF FILLING THEN
.    START BREAK;
.    IF LINES<2*SPREAD+1 THEN NEXT PAGE END
.  ELSE SKIP SPREAD⊃;

.COMMENT PICTURE MACROS;
.FIGS←TRUE;
.RECURSIVE MACRO STOREPIC(TITLE,LINES,TEMP) ⊂START
.PICLIN←PICLIN&"  "[1 TO 2-LENGTH("LINES")]&"LINES";
.PICNUM←PICNUM&"    "[1 TO 4-LENGTH(TEMP)]&TEMP;
.PICTLEN←PICTLEN&"  "[1 TO 2-LENGTH(LENGTH("TITLE"))]&LENGTH("TITLE");
.PICTIT←PICTIT&"TITLE";
.END⊃

.BOTTOM←50;
.MACRO FULL⊂BOTTOM-3*SPREAD⊃
.MACRO HALF⊂BOTTOM/2-3*SPREAD⊃
.MACRO THIRD⊂BOTTOM/3-3*SPREAD⊃
.MACRO TWOTHIRDS⊂2*BOTTOM/3⊃

.MACRO NEWFIG(TITLE,εLINES,LABEL) ⊂
.FIGURE←FIGURE+1; LABEL TEMP←FIGURE; }Figure {TEMP;
.STOREPIC(|TITLE|,LINES,TEMP) ⊃;

.MACRO FIGREF(LBL)⊂"Figure ";   LBL⊃

.MACRO MAKEFIG(TITLE,εLINES,LABEL) ⊂
.FIGURE←FIGURE+1;LABEL TEMP←FIGURE;
.STOREPIC(|TITLE|,LINES,TEMP) ⊃;

.PICLIN←PICNUM←PICTLEN←PICTIT←NULL
.MACRO SMALLPIC⊂⊃
.MACRO ALLPIC⊂⊃

.IF FIGS THEN START

.MACRO PLACEPIC ⊂BEGIN CENTER PREFACE SPREAD-1
.A←PICLIN[1 TO 2]; B←PICNUM[1 TO 4];
.C←PICTLEN[1 TO 2]; D←PICTIT[1 TO C];
.PICLIN←PICLIN[3 TO ∞]; PICNUM←PICNUM[5 TO ∞];
.PICTLEN←PICTLEN[3 TO ∞]; PICTIT←PICTIT[C+1 TO ∞];
.GROUP SKIP A;
Figure {B}
{D}
.SKIP 2*SPREAD;
.END⊃

.RECURSIVE MACRO RSPIC ⊂
.IF LINES-3*SPREAD≥PICLIN[1 TO 2] THEN PLACEPIC
.ELSE START
.	TLIN←TLIN&PICLIN[1 TO 2]; PICLIN←PICLIN[3 TO ∞];
.	TNUM←TNUM&PICNUM[1 TO 4]; PICNUM←PICNUM[5 TO ∞];
.	C←PICTLEN[1 TO 2];
.	TTLEN←TTLEN&C; PICTLEN←PICTLEN[3 TO ∞];
.	TTIT←TTIT&PICTIT[1 TO C]; PICTIT←PICTIT[C+1 TO ∞];
.	END;
.IF PICLIN≠NULL THEN RSPIC⊃

.RECURSIVE MACRO SMALLPIC ⊂
.TLIN←TNUM←TTLEN←TTIT←NULL;
.RSPIC;
.PICLIN←TLIN; PICNUM←TNUM; PICTLEN←TTLEN; PICTIT←TTIT;
.IF LINES<2*SPREAD-1 THEN NEXT PAGE ⊃

.RECURSIVE MACRO ALLPIC ⊂
.IF PICLIN≠NULL THEN SMALLPIC;;
.IF PICLIN≠NULL THEN BEGIN PLACEPIC; ALLPIC END ⊃

.AT NULL ⊂IF FILLING THEN
.    START BREAK;
.    COMMENT IF LINES<2*SPREAD+1 THEN NEXT PAGE; END
.  ELSE SKIP SPREAD⊃;

.BEFORE PAGE ⊂STANDARD TITLES;
.    IF PICLIN≠NULL THEN SMALLPIC ⊃

.END COMMENT PICTURE MACROS;
 
.device xgp
.IF XCRIBL THEN FONT 1 "BASL30[HAL,HE]"
.IF XCRIBL THEN FONT 4 "BASI30[HAL,HE]"
.IF XCRIBL THEN FONT 5 "BASB30"
.IF XCRIBL THEN FONT 6 "BDR40";
.COMMENT IF XCRIBL THEN FONT 7 "LPT";

.!xgplftmar← 200
.PAGE FRAME 28 HIGH 80 WIDE;
.TITLE AREA HEADING LINES 1 TO 2 CHARS 1 TO 80;
.AREA TEXT LINES 3 TO 28 CHARS 1 TO 80;
.TURN ON "%\"
.TABS 17
.SECID←"SECTION";
.SECNAME←NULL
.COUNT PAGE FROM 1 TO 999 PRINTING ⊂PAGE⊃;
.IF XCRIBL THEN SELECT 1 

.NEXT PAGE
.SSECNAME←NULL;
.PORTION TITLEPAGE
.BEGIN NOFILL;turn on "↑";SPREAD←1;
.AREA TEXT LINES 1 TO 28 CHARS 1 TO 80
.NEXT PAGE
%1STANFORD ARTIFICIAL INTELLIGENCE LABORATORY →APRIL 1975
.GROUP SKIP 4
.NOFILL CENTER
%6An Overview of AL, A Programming System for Automation
.GROUP SKIP 2
%1Raphael Finkel, Russell Taylor, Robert Bolles, Richard Paul↑*, Jerome Feldman↑*


.GROUP SKIP 2
.FILL ADJUST COMPACT
.NARROW 8,8
AL is an high-level programming system for specification of manipulatory tasks
such as assembly of an object from parts.
AL includes an ALGOL-like source language,
a translator for converting programs into runnable code, and a runtime system
for controlling manipulators and other devices.  The system includes
advanced features for describing individual motions of manipulators, for using
sensory information, and for describing assembly algorithms in terms
of common domain-specific primitives.  This paper describes the design
of AL, which is currently being implemented as a successor to the Stanford WAVE
system.
.WIDEN
.NOFILL SKIP TO LINE 21
.FILL
∞_→#
.BREAK
%4↑* Jerome Feldman is now at the University of Rochester.
Lou Paul is now at the Stanford Research Institute.

This research was supported in part by the
National Science Foundation under contract No. GIα-42906 and in part by
the Advanced Research
Projects Agency of the Office of Defense under Contract No. DAHC-15-73-C-0435.
The views and conclusions in this document are those of the authors and 
should not be interpreted as necessarily representing the official policies,
either expressed or implied, of the
funding agencies.
.END

.ADJUST COMPACT
.SECNAME←NULL
.SSECNAME←NULL
.SSSNUM←NULL
.PORTION BODY;
.COUNT PAGE FROM 1 TO 999 PRINTING ⊂PAGE⊃;
.EVEN HEADING(Page {PAGE!},{SSECNAME},{SSSNUM});
.ODD HEADING({SSSNUM},{SSECNAME},Page {PAGE!});
.NEXT PAGE
.NEWSEC AN OVERVIEW OF AL

This short paper cannot cover the subject of AL with any depth;
a complete discussion may be found in %4AL, A Programming System
for Automation%*, Stanford Artificial Intelligence Laboratory Memo
AIM-243, Stanford University Computer Science Department Report
STAN-CS-74-456, by the authors of this paper.

.NEWSS INTRODUCTION

The development of robot manipulators such as the "Unimate" has led
to the belief that these tools are in some way general-purpose
devices and that they might be programmed like a computer.  As a
general-purpose programmable device, the robot manipulator 
provides an answer to the need for automation of assembly in batch
manufacturing industries where small production runs rule out
the use of special-purpose equipment. 

We are implementing a system called AL for small scale batch manufacturing where
setup time is the key factor. We rely on a symbolic database
and previously-defined assembly primitives to minimize
programming time. The system is capable of top-level planning
and intelligent interpretation of user defined primitives. 
The principal aim of this work is not to provide a factory floor
programming system but rather 
to design a language which will be
a tool for
investigating the difficulty, necessary programming time, and
feasibility of writing programs to control assembly operations. 

.NEWSS PHILOSOPHY OF DESIGN 

.NEWSSS DATA AND CONTROL STRUCTURES

The principal mode of input to AL is
textual, as opposed to spoken or manual (joystick).  There are levels
of complexity which are much more readily transmitted from man to
machine through an interface of symbolic text.
Simultaneous motions of two arms and termination
and error conditions are more likely to be unambiguously described
through the medium of text; the structure
imposed on the textual language forces a consistent framework on
initially less structured intuitive ideas.  Non-textual forms of
input for defining target locations and
suggesting arm trajectories to avoid collisions
are most useful when applied in conjunction with a program text which
supplies the skeletal intent of the programmer.
The supervisor level of AL is simple enough to allow
natural teaching by showing; it should be easy to interface such
devices as joysticks and vocal input into AL, although we
do not intend to do so at present.

Experience with languages like SAIL and WAVE has shown that text macros are a
useful feature; they reduce the amount of repetitive
typing.  AL has a general-purpose text macro system
interfaced into the scanner and parser. 

The datatypes available include those types necessary to refer to
one-dimensional measures (like distance, time, mass) and
three-dimensional measures (like directed distance, locations,
orientations). Arithmetic operators are available not only for
the standard scalar operations like multiplication and addition, but
also for such operations as rotation and translation. 

Provision is made for
simultaneous execution of several processes  This allows
calculation
and arm motion to take place simultaneously; several
manipulators can be in independent or coordinated motion. 

.NEWSSS MOTION SPECIFICATIONS

Experience with WAVE has shown that calculating trajectories for
manipulators is desirable but time-consuming. 
Trajectory calculations, together with all other calculations which
need only be performed once, are done at compile time.  This
allocation of effort drastically reduces the computing load at
execution time and eliminates wasteful recomputation every time a
sequence of actions is executed.  This leads to a clear distinction
between compile-time and runtime. 
Trajectories may be specified to pass through
given intermediate points.  The primary use of this is to avoid
collisions during the motion.  It is also useful in specifying
complicated motions. 

A wide range of exceptional conditions can occur during the motion of a
manipulator.
Appropriate action must be taken as soon as any
of these occurs, for example to start up a new concurrent process
or to notify the user.
Therefore, AL allows the
flexible specification of conditions to monitor during the
course of motions (and during execution of blocks of code in
general), and what to do in the case that a tested condition occurs.


.NEWSSS USE OF A PLANNING MODEL

Since locations are not known exactly during the planning of a
trajectory, there is a clear distinction between planned
values and runtime values.  Planned values are used for
trajectory calculation; at runtime, trajectories are modified if
necessary to account for any discrepancies. The planned values are
therefore a database on which trajectory calculations are computed. 
This database forms a %4world model%*. 

Assembly tasks require that one object be affixed to another.  We
model this by having a semantic attachment between objects. 
If two objects are affixed, and
one moves, the second one should move accordingly, that
is, its planning value should be properly modified. The world
model includes information on attachments of objects.
The affixment
concept carries over to the runtime system, which does the equivalent
modifications of the actual values.  This saves the user untold
bookkeeping operations to determine where an object is after its base
has been moved. 

More generally, 
the compiler maintains a wide variety of information
about expected runtime states.  This includes 
information like the accuracy within which the planning
value is known, how heavy an object is, how many faces it has on
which it can rest, how wide the fingers of an arm should open to
grasp it.  This information may come from several sources, including
explicit assertions by the user
and built-in knowledge about the system hardware.  
AL has a general framework for representing
and using such knowledge.

.NEWSSS USE OF DOMAIN-SPECIFIC KNOWLEDGE

The system has enough domain-specific knowledge to allow
programs to be written in terms of common assembly operations, rather
than exclusively in terms of detailed single motions.  At the
simplest level, this involves a library of common
assembly "macro-operations" that can be conditionally expanded to
perform particular subtasks.  Beyond this, we foresee an
interactive system that can take a "high level" description of an
assembly algorithm and fill in many of the detailed decisions
required to produce a consistent and efficient output program.  

A user can specify different parts of a task at various
levels of detail.  The system accepts explicit advice
telling exactly how some particular subtask is to be accomplished and
then completes the program in a way that does not conflict with that advice.
This is especially
important for early versions of AL, which are not likely to be very
"smart" and will therefore require a fair amount of explicit help. 

The user can make assertions describing the "intent" of a particular
piece of code by specifying any (non-obvious)
prerequisites or updates to the world model.
Such information can be used by the AL strategist to generate
code to cause the desired result.
  This facility is
especially important for programs that mix both high and low-level
primitives. Similarly, the system can show the user how
it is filling in the details to produce an output program, and why. 
This is very important both for debugging and for explaining to the
user any requests for advice that it must make. 

.NEWSSS THE RUNTIME SYSTEM

The calculation of trajectories is time-consuming but not
time-critical; servoing of devices is time-critical but not
especially time-consuming.
The compiler is written in a high-level language, SAIL, and
the runtime programs are written in assembly language.
As one
execution computer will be required for each work station in a
factory, and as the runtime code and its memory requirements will be
quite small, the runtime system is designed for a minicomputer.

The runtime system supports simultaneous executions of many
processes.  Several manipulators 
or devices
might be running simultaneously, and each
motor requires a separate process; several condition
monitors might be active; several code segments (doing, perhaps,
calculations) might be simultaneously active.  Those processes which
are dealing with real-time devices (joint servos and condition
checkers) must be guaranteed service at regular intervals; the
computation processes can fill in any time gaps. 

Trajectories are calculated by the compiler on the basis of
incomplete information.  At runtime, it is necessary to modify those
plans to fit them to the somewhat different actual location of
objects.  Certain information must be carried at
runtime to accomplish this modification.

The wide range of conceivable tasks implies that pure hardware
servoing does not in general suffice.  The reason for this is that
hardware servoing restricts use to one of a small number of servo
modes (typically position, velocity, or force), and has no provision
for motions of accommodation or motions whose modes might change in
midstream due to some software-detectable condition.  Pure hardware
servoing could not be readily modified to account for new feedback
devices or methods.  A philosophy of %4software servoing%* has these
advantages: It is possible to program the manner in which feedback is
to be used, to interface new types of sensors, 
to modify the servo while the arm is in motion,
to supply the driving program with information concerning
the success of the motion as well as to keep it up-to-date on the arm
status.
It also allows coordination of several arms, with one acting as
a master and the others following.
  Hardware servoing would not save
computation since the
computer would need to perform an
equivalent
 servo calculation in order to understand
what the manipulator is doing to interact with the task. 

.NEWSS GENERAL SYSTEM OUTLINE

.NEWSSS HARDWARE

	Currently  two  Stanford  Electric  Arms,   built  by  Victor
Scheinman [Scheinman], are available.  They are called YELLOW and BLUE.  Each has
six joints  and a hand  that can  open and  close.   The joints  are
controlled by  electric motors; each joint has both position
and velocity feedback.
Motor  drives are sent from the computer to
the arm via a  digital-to-analog converter (D-to-A); feedback  signals are
routed through an analog-to-digital converter (A-to-D) back to the computer.

	Various other devices are designed and implemented as needed.
We use tools, jigs and special markings for several purposes:
to render a task possible (an example is the arm itself), to improve
efficiency (a mechanical screwdriver), and to overcome some of our
sensory and mechanical limitations (a screw dispenser).

	AL  resides on two  computers: The PDP-10  for all planning,
and a PDP-11/45 for the execution of the plans.  The former is run  as a
timesharing computer  (under a  modified DEC  system); the  latter is
operated  in  stand-alone mode under  the AL  runtime system.
 Each
computer is capable of generating an interrupt in the  other, and the
PDP-10 has complete control over the PDP-11 console and unibus.
It is not certain exactly what the minimum runtime computer configuration
will be; we use floating point and memory management, but it is not
clear that this is altogether necessary.


.NEWSSS SOFTWARE

	See {NEWFIG Overall system, TWOTHIRDS, sis←} for a picture of the
system. 

	The SUPERVISOR is the top level of AL.  It runs on
the timesharing computer
 and provides an interface between the user and the other
parts of the system: 1) listening to the user's console and
interpreting simple command language input; 2) controlling the
compiler, starting it and relaying its error messages back to the
user; 3) signalling the loader when it is necessary to place compiled
code into the mini; 4) handling the runtime interface to the mini. 

	The USER sits at a console and makes requests of AL.  These
fall into several categories: compilation, loading, execution of
programs, debugging of code, requesting of status information, asking
for immediate arm motion, saving and restoring the state of the world
at safe points, requesting explanation of certain compiler decisions. 
There are two different consoles at which a user can sit:
one is connected to the timesharing computer,
through which she can speak to the supervisor
and all the parts of AL residing on the timesharing
computer; the other is connected
to the mini, and through it the user can investigate the runtime
system and cause modifications.

	The COMPILER reads AL programs from files (or, optionally,
directly from the user's console) and produces load modules.  The
compiler is divided into three phases: The PARSER,
which produces parse trees of the program,
 the EXPANDER,
which expands those parse trees by replacing high-level primitives
with low-level primitives, and
the TRAJECTORY CALCULATOR and CODE GENERATOR, which creates the
output files.

	The LOADER takes the load modules prepared by the compiler
and enters them into the mini's runtime system.  Address relocation
and linking are done at this time. The loader also sets up the data
area in the runtime interface in the timesharing
computer; these data include
output strings, procedure linkages, and information necessary for
diagnostic purposes during runtime.  Loading is often done in a
partially incremental fashion, installing new code following
previously loaded code.  

	The RUNTIME INTERFACE, which resides in the
timesharing computer, is charged with initiating the mini
program, fielding procedure calls from the running program to
procedures on the timesharing machine,
returning values from these procedures, and
fetching values from the mini for debugging purposes.  The
interface has the power to interrupt the execution of the program and
to modify the status of the runtime system, for example, by patching
in additional programs or modifying the values of some variables.
This allows the user to control the program through the timesharing
computer.

	The RUNTIME SYSTEM is the set of programs which reside in the
mini.  This system includes kernel programs for time-slice cpu
sharing and process control and a set of dynamically created
processes.  These are of three basic types: a) An INTERPRETER
examines the code prepared by the compiler and executes the numeric
computations requested.  When a move is to be started, the
interpreter creates a servo for each joint and waits until all these
servos are finished.  b) A SERVO handles the motion of one moving joint. 
c) A CONDITION-MONITOR repeatedly examines certain conditions
(whatever the programmer has specified).  If it should discover that
its condition has occurred, it creates an interpreter to take
appropriate action.  
The runtime system also includes routines for communication with the
runtime interface in the timesharing computer.

.NEWSEC AN EXAMPLE

       A simple task dealing  with the objects shown in
{NEWFIG Layout for Example,TWOTHIRDS,lay←}
 illustrates some
of the features of AL:
.BEGIN SPREAD←0;PREFACE 0;INDENT 10,10
	1.  Pick up the bracket with the YELLOW arm and position it next to
	    the beam so that the holes line up,

	2.  Pick up the bolt with the BLUE arm,

	3.  Fasten the bracket to the beam by inserting the bolt in the holes,

	4.  Return the arms to their park positions.
.END
Some of the features to be demonstrated are: the affix structure,
reference frames, dimensions, and multi-processing.  We demonstrate
these capabilities by presenting a highly commented AL program to
accomplish the task stated above. 

 AL is a multi-level programming language; at one extreme the user
can write detailed, system-like programs and at the other she can
describe the tasks and any partial ordering among them and let the
system determine necessary details.  Our example is written in an
intermediate level.  In particular, it assumes that there are several
general-purpose macros and routines which understand how to GRASP and
RELEASE things and carry out a NORMAL_SEARCH to insert something into
a hole. 

         Capitalized words in  the example are  key words  within AL.   Lower case
words are user-defined identifiers.  Comments are surrounded by curly brackets. 

.BEGIN "EXAMPLE";NOFILL;INDENT 0,0;PREFACE 0;
whole_task: BEGIN 
.COMT 4
    α{First declare the necessary FRAMEs and describe how they are
    initially related.  The attach structure representing the initial
    world is shown in 
    {NEWFIG Attach Structures for the Task Example,FULL,ats←}.
    The arrows indicate how the movement of a
    frame affects other frames.  If a frame at the tail of an arrow
    is moved (by the arm, visually updated, etc.) the frame at the
    head of the arrow will be automatically updated.  The double
    arrows are the results of RIGIDLY AFFIXing one frame to
    another.α}
.END
FRAME beam, beam_hole;	        FRAME bolt;
FRAME bracket, bracket_hole, bracket_grasp;
beam α← FRAME(ROT(Z, 90*DEG), VECTOR(10,6,0));
.COMT 4
    α{The  beam is  expected to  be  positioned at  (10,6,0)  in the  station's
    coordinate  system (all  measurements are in  centimeters) and  rotated 90
    degrees about the station's Z vector.  AL knows about dimensions  like DEG
    for degrees.  Dimensions are adjuncts to variable types; new ones can
    be defined in terms of old ones.α}
.END
beam_hole α← beam*TRANS(ROT(X, 90*DEG), VECTOR(3,0,7));
.COMT 4
    α{The TRANS represents  the position of  the beam_hole with respect  to the
    beam.  The  premultiplication by the frame beam positions the beam_hole in
    the station's coordinate system.α}
.END
AFFIX beam_hole TO beam; %4α{As shown in {FIGREF ats}α}%*
ASSERT FORM(DEPROACH, beam_hole, TRANS(NILROT,VECTOR(0,0,-3));
.COMT 4
    α{Trajectories consist  of a  path from  the current  position, through  a
    departure  point, possibly  through some via  points, through  an approach
    point, and finally to the destination.   All FRAMEs have a DEPROACH  TRANS
    associated  with  them.   TRANSes  are  essentially  the same  as  FRAMEs.
    Whenever  leaving  (or  moving  to) a  FRAME  the  standard  departure (or
    approach) used is that FRAME's DEPROACH TRANS.  The station has a DEPROACH
    TRANS which  is three inches above  it.  Whenever one FRAME  is AFFIXed to
    another, by default the former takes on the later's DEPROACH.   The result
    of this ASSERT
    is that the arms will  approach the beam  hole from the side instead of from
    above. 
.END
bracket α← FRAME(ROT(Z,45*DEG),VECTOR(20,14,0));
bracket_hole α← bracket*TRANS(ROT(X,180*DEG),VECTOR(3,3,0));
AFFIX bracket_hole TO bracket;
bracket_grasp α← bracket*TRANS(ROT(X,180*DEG),VECTOR(0,3,3));
AFFIX bracket_grasp TO bracket RIGIDLY;
.COMT 4
    α{The  RIGID  AFFIXment  insures  that  a   change  of  bracket_grasp  will
    automatically  change  bracket, which  in turn  will  automatically change
    bracket_hole.   This is  quite convenient  if the  position  of the  whole
    `object' is being updated by one grasping position (ie. bracket_grasp).α}
.END
bolt α← FRAME(ROT(Z,90*DEG)*ROT(X,180*DEG),VECTOR(16,30,0));
.COMT 4
    α{The rotation portion of the FRAME has been  specified as a composition of
    two primitive rotations.α}
.END
DEFINE OZ = "72.007789*DYNES";
.COMT 4
    α{Some of the standard macros are defined next.α}
.END
DEFINE grasp(TRANS special_departure,special_approach;
    FRAME ATOM the_arm (DEFAULT YELLOW);
    FRAME object,grasp_point,thing_object_affixed_to;
    DISTANCE SCALAR opening_before_departure,
	opening_for_approach(DEFAULT 15*CM),
	thickness(DEFAULT .3*CM)) = " ... ";
.COMT 4
    α{The expansion of such a macro can depend upon the supplied arguments, the
    DEFAULT arguments, and any values in the current planning model.α}
.END
DEFINE release(FRAME ATOM the_arm(DEFAULT YELLOW);
    FRAME the_object,the_new_parent;
    DISTANCE SCALAR the_opening(DEFAULT 15*CM)) = " ... ";
DEFINE normal_search(FRAME ATOM the_arm(DEFAULT YELLOW);
    DISTANCE SCALAR increment(DEFAULT .3*CM), distance_fwd;
    FORCE SCALAR stopping_force;
    SCALAR number_of_tries(DEFAULT 9)) = " ... ";
.COMT 4
    α{This includes some automatic error recovery and a call to the operator if
    something drastic goes wrong.α}
.END
COBEGIN 
.COMT 4
    α{This COBEGIN-COEND  construction describes two  independent
    subtasks (one  for YELLOW and one  for BLUE) which can  be executed in any
    order determined by the runtime system; in parallel or serially.  This, of
    course, assumes that the two arms work in completely separate parts of the
    workstation so there is no possibility of a collision.α}
.END
    ypickup: BEGIN %4α{pick up the bracket with yellowα}%*
    grasp(object=bracket,grasp_point=bracket_grasp,opening_for_approach=3*CM);
.COMT 8
        α{Only the necessary parameters  need to be specified.   By default the
        YELLOW  arm will be  used and there  will be no  special approaches or
        departures.  One effect of grasp is to AFFIX the object to the arm.α}
.END
    MOVE bracket_hole TO beam_hole + VECTOR(0,0,-.3) WRT beam_hole;
.COMT 8
        α{The YELLOW arm (since  it holds the bracket to  which bracket_hole is
        AFFIXed) positions  itself so that the bracket_hole  lines up with the
        beam_hole, but is .3 cm away from  the beam_hole.  The WRT operator  is
        one way of describing a vector  within a frame of reference other than
        the station's.α}
.END
    MOVE YELLOW TO ⊗ + VECTOR(0,0,.6) WRT beam_hole
        ON FORCE(Z WRT beam_hole)>50*OZ DO STOP YELLOW
	ON ARRIVAL DO ABORT("***  error   ***  bracket  went  too  far");
.COMT 8
        α{The ⊗ represents the current position of the arm.  The arm moves .6 cm
        in Z  relative to the beam_hole's frame.  The  purpose of this move is
        to push the bracket up  against the beam.   If the beam is there,  the
        arm will  sense an opposing  force.  If not,  the arm will  succeed in
        moving  forward the  prescribed  .6 cm.   In order  to check  for these
        possibilities, two condition monitors have been included with the MOVE
        statement.  The first one  monitors the force and stops the arm if the
        force exceeds 50 ounces  (which means everything is  ok).  The  second
        one is an interrupt  type condition.  If the  arm successfully carries
        out  the  complete MOVE,  this  monitor is  awakened,  the  message is
        printed, and control is given to an operator.α}
.END
    END ypickup;
    bpickup: BEGIN  %4α{pick up the bolt with blueα}%*
    grasp(the_arm=BLUE,the_object=bolt,grasp_point=bolt,
        opening_for_approach=3*CM);
    END bpickup;
COEND;
.COMT 4
    α{{FIGREF ats} shows the world after the parts have been picked up.α}
.END
MOVE bolt TO beam_hole + VECTOR(0,0,-5.3) WRT beam_hole;
.COMT 4
    α{The BLUE  arm positions  itself so  that the  bolt is lined  up with  the
    beam_hole and its tip is .3 cm away from the outside of the bracket_hole.α}
.END
normal_search(BLUE, .2*CM, 1.6*CM, 60*OZ, 9);
.COMT 4
    α{This pushes the bolt thru the bracket_hole and partly into the beam_hole.
    If control continues  past this statement the bolt is assumed to be partly
    in the hole.α}
.END
MOVE BLUE TO ⊗ * FRAME(ROT(Z,90*DEG),VECTOR(0,0,4))
    ON FORCE(Z WRT BLUE) > 60*OZ DO STOP BLUE;
.COMT 4
    α{This pushes and twists the bolt into the hole.  When the force exceeds 60
    ounces, the bolt is assumed to be completely seated in the hole.  There is
    no check to make sure the bolt seats properly.α}
.END
COBEGIN
    parky: BEGIN  %4α{release the bracket and parkα}%*
    release(the_object=bracket,the_opening=3*CM,the_new_parent=beam);
    MOVE YELLOW TO YPARK;
    END parky;
    parkb: BEGIN  %4α{release the bolt and parkα}%*
    release(the_arm=BLUE,the_object=bolt,the_opening=3*CM,the_new_parent=beam);
    MOVE BLUE TO BPARK;
    END parkb;
COEND;
END whole_task
.END "EXAMPLE"
.NEWSEC CONCLUSIONS

AL is important for several reasons.  It shows what sort of
considerations are necessary for flexible control of mechanical
manipulation.  It demonstrates the feasibility of programmable
assembly.  It provides a research tool for investigation of new modes
of software servoing, assembly primitives, arm-control primitives,
and interactive real-time real-world systems. 

AL is currently limited by the lack of certain features which would
make it more competent.  Many of these have to do with the fact that
feedback is used only in a threshold way; either a monitor triggers
or it does not.  Fine control of the arm would be enhanced by more
sensitive force-sensing elements on the hand and a means of
programming accommodating, non-threshold response to this sensory
input.  Visual feedback should be implemented to provide better
positioning capability, error detection, and error recovery.  Moving
assembly lines imply that AL should be able to handle motions which
it does not cause directly through manipulation; objects should have
a dynamic capablility.  Collision detection and avoidance remain
difficult issues.  AL would be more error-free if the trajectory
calculator could ensure that the arms never interfere with each other
or with objects in the current world.